fix(firestore): honor database-scoped resource selectors - #11461

In the single database configuration path, the code does not combine global and database-scoped resource selections. If selection.allDatabases is true (e.g., due to a global selector like firestore:rules), it directly uses selection.allResources and completely ignores any database-scoped selectors defined in selection.byName.\n\nThis is inconsistent with the multi-database array path below, which correctly merges both global and database-scoped resource selections for each database. This discrepancy was not caught by the tests because fsConfig.spec.ts only tests the array configuration, and prepare.spec.ts stubs getFirestoreConfig to return an array.

      const resources = new Set(selection.allDatabases ? selection.allResources : []);\n      for (const r of selection.byName.get(databaseId) || []) {\n        resources.add(r);\n      }

🔴 [Error Remediation & Exit Status] Provide actionable remediation and { exit: 1 }

Rationale: Per firebase-tools CLI error standards, user input validation errors thrown with FirebaseError must specify a non-zero exit code ({ exit: 1 }) and provide actionable remediation explaining the accepted target format.

Suggested Fix:

🔴 [Error Handling & UX] Single-database configurations silently ignore non-matching database targets

Rationale: In multi-database mode (Array.isArray(fsConfig)), lines 159–166 throw a FirebaseError if selection.byName specifies a database target not found in firebase.json. However, in single-database mode (!Array.isArray(fsConfig)), lines 110–112 simply return [] when !selection.byName.has(databaseId).

When getFirestoreConfig returns [], src/deploy/firestore/prepare.ts exits cleanly, leading firebase deploy to report "Deploy complete!" while silently deploying nothing. Single-database mode should validate selection.byName and throw an informative FirebaseError with { exit: 1 } if any requested database target does not match databaseId.

Suggested Fix:

      if (!selection.allDatabases && !selection.byName.has(databaseId)) {
        const unmatched = [...selection.byName.keys()];
        throw new FirebaseError(
          `Could not find configurations in firebase.json for the following database targets: ${unmatched.join(", ")}`,
          { exit: 1 },
        );
      }

🟡 Nit: Avoid as ParsedFirestoreConfig type assertion

Rationale: In the target branch above (line 141), { database, rules: c.rules, indexes: c.indexes } is constructed explicitly. In this database branch, using c as ParsedFirestoreConfig bypasses TypeScript compiler checks and preserves extra properties from c. Constructing the object explicitly is cleaner and avoids loose casting.

Suggested Fix:

🟡 Nit: Specify { exit: 1 } on FirebaseError

Rationale: Per firebase-tools CLI standards, configuration and input assertion errors thrown with FirebaseError should explicitly specify { exit: 1 }.

Suggested Fix:

🟡 Nit: Add unit test coverage for single-database configs and target aliases

Rationale: makeOptions in fsConfig.spec.ts currently sets firestore as an array (multi-DB). Adding test cases covering single-database configurations (e.g. firestore: { rules: "...", indexes: "..." } with --only firestore:rules, --only firestore:(default):rules, and unmatched database target rejection) will ensure full permutation coverage and prevent regressions across both configuration schemas.